home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Atari Mega Archive 1
/
Atari Mega Archive - Volume 1.iso
/
lists
/
gem
/
l_0799
/
438
< prev
next >
Wrap
Internet Message Format
|
1994-08-27
|
4KB
Date: Mon, 13 Jun 94 01:07 CDT
From: ekl@sdf.lonestar.org (Evan K. Langlois)
To: gem-list@world.std.com
Subject: Re: The Undigestable Digested
Precedence: bulk
On DELETE, ClrHome, and related topics. It's pointless to add keys and
to purposely make things difficult for the user! That is what you are
doing by adding keys. Make it easy!! We DO have a key labelled UNDO
you know! UNDO is when you make a boo-boo and didn't mean to press that!
As to unintentionally overwritting your document with the "big cursor" and
the whole ^A thing, how about this - if you start typing, it does NOT
overwrite the block. I really hate the idea that to overwrite a word,
you select it and type a new one. It doesn't seem natural. Simply have
the user tap DELETE to get rid of a block before typing new data. That
way ^A is still select ALL, DELETE is still easy, you can't lose your
document unless you hit ^A by mistake, then DEL by mistake, AND your
UNDO key is broken! Keep the hot-keys simple. Don't try and make things
more difficult to protect the user from himself ... just make it easy to
fix too!! Tapping delete before you overwrite a block (so you delete and
then insert instead of overwrite) isn't so bad is it?
As to the UNDO. UNDO is UNDO last command. You keep hitting it and
you'll UNDO the UNDO or whatever the last operation was. Shift-UNDO
would be the command to UNDO the next operation in the buffer, if the
application supported such. CTRL-UNDO, which no one will ever hit by
accident, is Abandom Changes, or UNDO All. This could be undone with
UNDO. If you make a mistake - PANIC! Hit UNDO! It should always
work no matter what! Re-Do should be ^G since that is already used
for Search Again .. change it to ReDO. So, if you searched last, ^G
is search again. If the last thing you did was delete a line, ^G
does that again. I think it makes sense this way.
I'm against double-click dragging. That is just too many operations to
decipher for one command, for both user and programmer! I think it was
Christian that mentioned that Drag-n-Drop was a move, not a copy. My
docs don't mention that. I think it should always be a copy. If
you don't want to keep the data, tap delete. Simply don't deselect the
block when doing a drag-n-drop. This follows my guideline above about
the overwrite thing, especially since as soon as the user types an alpha
key, the block will be deselected anyway (following above guideline).
As to "mouse scrolling". I kinda like the idea of grabbing a window
with the right mouse button and dragging it across the screen in real
time, like GEMVIEW or PICSWITCH. I find this to be really handy and
quite intuitive and I prefer it for scrolling over using the scroll
bars. Also, since this is a drag operation, you can still use a
right "click" for other things. Personally, I think the right
mouse button is best for context/position sensitive pop-up menus, either
for windows, or on icons, or just on the background of the screen!
Manipulating background windows is already done, even by TOS's Desktop.
I think its either SHIFT or CNTRL and the left button. Basically, the
desktop lets you run a program from a "background" window this way, so
that the "top" window is the current directory yet the program runs in
that directory .. even though its in another directory entirely. Keeping
this same syntax for background windows makes alot of sense. Actually,
I think it should be possible to use any window that you can see something
in. So, if its shifted or control, then don't top the window, use it.
Oh .. don't bash MultiTOS. The GEM-List started out with a post about
how GEM has advanced to such-n-such an interface .. I don't remember the
wording, but bashing MultiTOS is not the answer. Bash ATARI for not
releasing the new one .. or rather for not getting the new one debugged
so that it can be released.